[00:00.000 --> 00:04.940]  Hi, I'm Mitch Parker, Information Security Officer at IU Health in Indianapolis, Indiana.
[00:04.940 --> 00:10.500]  And today's topic is going to be advancing medical device security, how collaboration
[00:10.500 --> 00:16.820]  between providers, manufacturers and pen testers is advancing what's possible with security.
[00:16.920 --> 00:21.740]  And with us today, we have an incredibly distinguished panel of people we've been able to find who
[00:21.740 --> 00:26.040]  I'd like to have introduce themselves right now. We're going to start with Florence Hudson.
[00:26.040 --> 00:30.140]  Very good. Thank you so much, Mitch, for having me join you. And hey,
[00:30.140 --> 00:38.040]  DEF CON crowd. Geeks and all. And goons. So I'm Florence Hudson, and I'm Founder and CEO of FDHint,
[00:38.040 --> 00:41.900]  which is an international consulting firm for advanced technology and diversity and inclusion.
[00:42.220 --> 00:47.520]  I also work for the NSF Cybersecurity Center of Excellence at Indiana University.
[00:47.520 --> 00:52.500]  I lead the Cybersecurity Research Transition to Practice Program. And I'm also Executive
[00:52.500 --> 00:56.560]  Director for the Northeast Big Data Innovation Hub at Columbia University,
[00:56.560 --> 01:00.860]  leading translational data science opportunities in the Northeast US.
[01:02.900 --> 01:10.520]  Oh, and I should say, I'm also Working Group Chair for IEEE UL P2933. For those who aren't
[01:10.520 --> 01:16.640]  acronym queens and kings, it stands for Institute for Electronic Engineers and Underwriters
[01:16.640 --> 01:21.640]  Laboratories. Working group on creating a standard around clinical innovative things,
[01:21.640 --> 01:27.260]  data, and device interoperability with TIPS, which stands for Trust, Identity, Privacy,
[01:27.260 --> 01:31.920]  Protection, Safety, and Security. And Mitch is one of our Co-Vice Chairs. So thank you very
[01:31.920 --> 01:35.880]  much for having me, Mitch. Thank you, Florence. We'll take it over to Rob Suarez.
[01:37.460 --> 01:43.500]  Hi. Hi, DEF CON. This is... My name is Rob Suarez, and I'm the Chief Information Security
[01:43.500 --> 01:50.460]  Officer for BD. That's Beckton Dickinson. And we're a global medical technology
[01:51.640 --> 01:56.480]  company offering some of the most advanced products across the continuum of care.
[01:56.620 --> 02:04.020]  It's my job at BD to make sure that we are protecting those products that we're delivering
[02:04.220 --> 02:09.600]  a secure product and also the environment in which they reside in, which is typically a hospital,
[02:09.600 --> 02:17.200]  but increasingly, you know, a patient bedside at home as well. And so I'm very excited to talk to
[02:17.200 --> 02:21.700]  my fellow panelists today about medical device cybersecurity. This is a passion of mine,
[02:21.700 --> 02:28.640]  and I've had the honor actually of working alongside Mitch and Michael as well on several
[02:28.640 --> 02:35.000]  industry initiatives. And so again, looking forward to the discussion today. Thank you.
[02:35.360 --> 02:42.400]  And last but not least, Mr. Michael McNeil. Hi, DEF CON. This is Michael McNeil. I'm the
[02:42.400 --> 02:47.640]  Senior Vice President and Global Chief Information Security Officer at McKesson,
[02:47.640 --> 02:56.280]  and just recently got to the organization. But as, you know, Rob has just stated, have had a
[02:56.280 --> 03:03.080]  number of years collaborating, you know, with the team here. And my days go back into
[03:03.080 --> 03:09.280]  Philips as well as into Medtronic from a medical device perspective over the past 10 years.
[03:09.280 --> 03:16.480]  Really looking forward to this particular session and again have collaborated with these guys in a
[03:16.480 --> 03:22.100]  number of different industry and forums. And again, I think you'll find our conversations
[03:22.100 --> 03:28.200]  today to be pretty enlightening because it takes that ecosystem and for us to come together
[03:28.200 --> 03:34.660]  to really execute here. Thank you so much, Michael. So I'm going to launch right into
[03:34.660 --> 03:39.720]  the first question here. First question is, what are the biggest concerns that each of you
[03:39.720 --> 03:47.800]  sees related to medical device security? So I'll start if I might. So what I mentioned
[03:47.800 --> 03:52.980]  when we were first opening up, I talked about tips, tips for the Internet of Things.
[03:53.080 --> 03:57.260]  This is a framework we've been creating with IEEE for four years now. As I mentioned,
[03:57.260 --> 04:02.300]  it stands for trust and identity, privacy, protection, safety, and security. I'm worried
[04:02.300 --> 04:07.080]  about all those things. I'm worried about the trust and identity of the devices, the device
[04:07.080 --> 04:11.880]  to device communication, the device to human, the doctor to the device to the human, human to
[04:11.880 --> 04:16.780]  everything. So I'm concerned about trust and identity, how we're going to maintain that and
[04:16.780 --> 04:22.020]  make sure we're vigilant about it. I'm concerned about privacy of data, whether you're in your home
[04:22.020 --> 04:26.180]  country or another country and what the different regulations are and how we're going to manage it.
[04:26.180 --> 04:30.380]  I'm concerned about protection and safety, how we're going to keep the humans safe, how we're
[04:30.380 --> 04:34.960]  going to keep the device safe, the infrastructure, the financial side of the institution, if your
[04:34.960 --> 04:40.240]  device is hacked and everybody finds out, like some of the FDA and DHS and U.S. CERT recalls.
[04:40.240 --> 04:46.620]  And I'm concerned about the cybersecurity. So we have a lot to do as the leaders in this space for
[04:46.620 --> 04:53.340]  IT and for cybersecurity and for medical devices. So I look forward to continuing the collaboration
[04:53.340 --> 04:58.280]  we're doing through groups like this and also like in the IEEE working group where we have
[04:58.280 --> 05:03.600]  over 250 humans from 22 countries and six continents who are worried about this too,
[05:04.120 --> 05:08.780]  including device manufacturers and providers and payers and regulators and everybody as we know,
[05:08.780 --> 05:13.580]  Mitch. So I'm worried about all that stuff. What about the rest of you? Are you worried?
[05:15.340 --> 05:24.300]  So I'll go next on that one. Thank you, Florence. For me, it's actually very similar to what you'll
[05:24.300 --> 05:31.200]  find was reported out and I believe it was 2017 and what was the healthcare industry
[05:31.200 --> 05:37.020]  cybersecurity task force report. In fact, on that task force, I got to serve alongside Michael
[05:37.020 --> 05:43.100]  McNeil and several other individuals across the industry and produce a report that outlined
[05:43.100 --> 05:50.680]  observations and recommendations for improving cybersecurity across the industry in healthcare.
[05:50.680 --> 05:56.280]  There was a specific section that was dedicated just for medical device cybersecurity,
[05:56.280 --> 06:02.520]  and I got to tell you, that was three years ago. A lot of those findings still apply to this day.
[06:02.800 --> 06:09.780]  And one that pops out to me immediately is that medical devices are in hospital settings for 15
[06:09.780 --> 06:17.620]  to 20 years, but new cybersecurity threats emerge daily. And every hospital and every patient
[06:17.620 --> 06:25.060]  environment is unique. So there's no one-size-fits-all approach. And at BD, we're
[06:25.060 --> 06:32.520]  working closely with healthcare providers on understanding medical device cybersecurity as it
[06:32.520 --> 06:38.620]  exists out in a clinical setting, out in the real world. And we're also working, we're really
[06:38.620 --> 06:46.080]  committed to transparency. And for example, providing coordinated vulnerability disclosures
[06:46.080 --> 06:54.420]  on medical device vulnerabilities. But unfortunately, it's just not enough. There's
[06:55.060 --> 07:02.640]  really a long time span to medical devices in these environments. And so increasing transparency
[07:02.640 --> 07:08.560]  absolutely helps, but we also need to build stronger relationships and stronger collaborations
[07:09.420 --> 07:14.980]  across... Florence, as you really described, across the continuum of stakeholders that we have
[07:14.980 --> 07:22.760]  when it comes to just using a medical device and managing it when it's in use.
[07:23.600 --> 07:32.520]  Yeah. And from my perspective to build on what Rob has just stated, he's hit the nail on the head,
[07:32.520 --> 07:40.800]  and we've been having these kinds of conversations and discussions even before the 2017 and earlier
[07:40.800 --> 07:50.320]  when we go back a few years on this particular topic. I think people have heard me talk in the
[07:50.320 --> 07:57.020]  past and it really doesn't... It's kind of interesting. It doesn't change. It just perpetuates
[07:57.020 --> 08:06.080]  itself. So as Rob just talked about, legacy devices as we call them in the ecosystem and how
[08:06.080 --> 08:13.020]  we manage that, that to me ties right into what I've always said is sort of the three deadly sins
[08:13.020 --> 08:19.340]  that I've kind of communicated over time. Because you have these types of devices, you need to make
[08:19.340 --> 08:24.100]  sure that you can patch and update them in a timely manner. So one of the deadly sins, if I
[08:24.100 --> 08:29.640]  can't patch and update a device, I'm not going to be able to maintain the security of that solution
[08:29.640 --> 08:37.100]  out in the marketplace. When I look at the types of devices and a number of them when they were
[08:37.100 --> 08:41.740]  designed and developed and they're in these environments, if they got hard-coded credentials,
[08:41.740 --> 08:46.940]  those are the keys to the kingdom. If I open the keys up and I let anybody come in, front, back,
[08:46.940 --> 08:52.900]  side doors, any way that you have, then you have access and you're going to be able to align.
[08:52.900 --> 08:59.280]  And then for us, when it comes to the type of information, again, as I would say that
[08:59.280 --> 09:05.380]  Florence had talked about in terms of thinking of the type of data and the type of information
[09:05.380 --> 09:12.000]  that needs to be held secure, if you don't do encryption and de-identify and make sure that
[09:12.000 --> 09:18.920]  that's not available to cause the kinds of harm to individuals, to the solution itself,
[09:18.920 --> 09:25.320]  you get to those deadly sins. So the sins are there and we're doing a much better job,
[09:25.320 --> 09:31.640]  I believe, in having an awareness around the design and how we need to build that into our
[09:31.640 --> 09:39.580]  solution set. But it's how do you manage that legacy that's sitting out there in the current
[09:39.580 --> 09:47.980]  environment? And as we've also said in the past, because of the nature of the marketplace,
[09:48.480 --> 09:57.140]  it's like prying those systems out of their cold, dead hands in some of these hospitals and other
[09:57.140 --> 10:03.860]  types of entities, because they don't have, obviously, with Mitch, the wherewithal to just
[10:03.860 --> 10:08.980]  immediately turn around, you know, your capital and your inventory for some of these types of
[10:08.980 --> 10:16.160]  solutions. Yeah, so I totally agree. It's the products we have today. It's the new products
[10:16.160 --> 10:21.720]  and how we create design-in plans so that you design in a defense-in-depth level of security
[10:21.720 --> 10:27.500]  at the hardware, firmware, software, and service level. I suggest we go all the way down to the IP
[10:27.500 --> 10:32.260]  of the design of the chip. You know, we need to go all the way down and all the way up.
[10:32.260 --> 10:37.400]  And we also need, I know in the standards work we're doing, we're saying that we need to be able
[10:37.400 --> 10:42.360]  to look forward too. I'm an old rocket scientist, or experienced. My girlfriend's saying not to
[10:42.360 --> 10:46.020]  use the term old, but I'm an experienced rocket scientist. I used to work on future missions
[10:46.020 --> 10:49.780]  around Jupiter. Did we know exactly what we were doing? No, but we had a planet, you know,
[10:49.780 --> 10:54.140]  and you look forward, you say, what's going to happen? So in the standards work that we're doing,
[10:54.140 --> 10:59.600]  we're agreeing that it has to be a standard that is extensible into the future. You know,
[10:59.600 --> 11:03.300]  so what we're also doing is envisioning, well, how can we use artificial intelligence
[11:03.300 --> 11:08.300]  and machine learning better? What about when it's a hologram and the doctor's like, oh my gosh,
[11:08.300 --> 11:12.300]  she's right here. You look a little jaundiced. I'm like, how do you know that? You know,
[11:12.300 --> 11:18.500]  I'm in my pajamas. How did that just happen? Right? So when we're in XR, AR, VR, how's all
[11:18.500 --> 11:22.900]  this stuff going to play? And then if you want to get excited about protocols, think of what,
[11:22.900 --> 11:26.500]  you know, communications protocol, that's going to be all about. You know, that's going to get
[11:26.500 --> 11:31.880]  into your EHR or how they're going to read, you know, from your, from your little devices. So
[11:31.880 --> 11:37.560]  we're also trying to think of what could happen. So being an aerospace engineer and designing,
[11:37.560 --> 11:42.660]  you know, not just spacecraft, but also planes and jets, you have your heads down display,
[11:42.660 --> 11:46.500]  right? Your altimeter. And then you have your heads up display. We need both.
[11:48.640 --> 11:53.810]  I am in full agreement with you and can tell you the biggest challenge I saw
[11:54.610 --> 12:00.430]  with all these years of working for healthcare and hospitals. I've been in the provider space
[12:00.430 --> 12:05.230]  for about a dozen years as a CISO. And biggest challenge I've always found has actually been
[12:05.230 --> 12:12.290]  paying for it all because a lot of, a lot of hospitals out there, especially with COVID,
[12:12.290 --> 12:19.630]  have significant financial challenges these days. And right now, I mean, every hospital
[12:19.630 --> 12:25.210]  has a problem paying. Before January or February of this year, you still would have had about,
[12:25.210 --> 12:29.270]  I'd say about half the hospitals in the United States, whereby I asked them to update a good
[12:29.270 --> 12:34.170]  chunk of their clinical engineering equipment. They would have likely looked at me and said,
[12:34.170 --> 12:38.930]  when I can fix my roof, when I can fix my floor, and when I can patch the hole in the boiler.
[12:39.510 --> 12:43.330]  And what do you want? Do you want a roof over your head or do you want secure medical devices?
[12:43.330 --> 12:49.110]  And I've actually once had a clinical chair from the department sit me down and say,
[12:49.110 --> 12:54.050]  I'd like to update my devices, but I need to get different ones in here because I'm not able to do
[12:54.050 --> 13:02.710]  women's health properly. And to me, that put a lot of items in perspective. And I've always worked
[13:02.710 --> 13:08.290]  with my customers to make sure that we can get them on at least a good path to where they need
[13:08.290 --> 13:14.910]  to be using minimal cost solutions. Because to be very blunt, it's 15 to 20 years also, because
[13:14.910 --> 13:20.510]  it's all I have money for. And that's sadly the situation in the United States. And after things
[13:20.510 --> 13:27.930]  happen, after we have some leveling off with COVID, we're going to be in a much different
[13:27.930 --> 13:33.530]  place, more like 2009 when it comes to the economy. But to get these good items in place,
[13:33.530 --> 13:38.490]  you need to have standards. And that leads me to the second question, which is, what standards
[13:38.490 --> 13:43.070]  efforts are in play for medical device security that you're currently working with? So again,
[13:43.070 --> 13:49.650]  to you, Florence, because of all the IEEE work. Absolutely. I have to apologize. I have a robo
[13:49.650 --> 13:54.610]  caller who won't give up. So you're going to hear my phone in the background. So anyone else been
[13:54.610 --> 14:01.770]  through this? So the standards efforts, we have a number of standards efforts in play, and we're
[14:01.770 --> 14:09.070]  trying to hold hands and work together. So at IEEE, we have this IEEE UL P2933, which is the
[14:09.070 --> 14:13.790]  for clinical IOT data and device interoperability with TIPS, as we discussed. There are also
[14:13.790 --> 14:19.190]  efforts on blockchain for healthcare and how that plays in. There are efforts going on with ISO and
[14:19.190 --> 14:25.810]  IEC and open mobile health and communications interoperability. So we actually just had a
[14:25.810 --> 14:30.690]  really cool session last week, where Mitch and I presented along with a number of our colleagues
[14:30.690 --> 14:36.350]  from around the world regarding addressing clinical IOT interoperability and security
[14:36.350 --> 14:42.490]  challenges globally. And so one of our colleagues representing Underwriters Laboratories,
[14:42.490 --> 14:47.650]  after we each spoke about P2933, you know, this kind of IOT thing, and then open mobile health,
[14:47.650 --> 14:52.650]  and a few other things, he got up and said, okay, here's one page with like all this stuff on it.
[14:52.830 --> 14:56.830]  You know, we have a pyramid here, we have a triangle, and we have all these other pieces.
[14:56.930 --> 15:01.530]  We have to figure out how we're going to work together. So if any of you out there are
[15:01.530 --> 15:07.470]  interested in getting involved in this, we're actually hoping to have a longitudinal plan here.
[15:07.530 --> 15:12.930]  We had Julian Goldman from Harvard, and Mass General, who was on the panel,
[15:12.930 --> 15:20.870]  and Ida Sim from UCSF. We had Mitch, me, Ken Fuchs, McGregor, Anura, Fernando from Underwriters
[15:20.870 --> 15:27.230]  Laboratories. And I always forget at least one. Oh, and Ken, I think that's most of it.
[15:27.230 --> 15:30.950]  And so we're all going to be getting together again in the fall. And we're interested in
[15:30.950 --> 15:35.570]  anybody else who wants to join us. So Mitch, I don't know if we're giving out our email addresses
[15:35.570 --> 15:45.330]  or how you want to do that. But, you know, we'll find a way to make the P2933 web page
[15:45.330 --> 15:53.030]  completely accessible and get information over there. So in the meantime, you can send me an
[15:53.030 --> 16:00.130]  email along with my robocaller at florence.com. And I think I'm going to give them my email address
[16:00.130 --> 16:02.570]  so they're not so disruptive the next time.
[16:04.090 --> 16:12.030]  Hey, Florence, I'm really excited to hear that IEEE is getting involved in this space.
[16:13.230 --> 16:18.350]  And, you know, it's exciting to hear that. There's not enough that we can do
[16:19.010 --> 16:24.570]  actually to really formalize the process of multiple device cybersecurity
[16:25.120 --> 16:32.030]  across the lifecycle of these technologies. I would like to also recognize, you know,
[16:32.250 --> 16:37.150]  a lot of the work that the FDA has done in producing cybersecurity guidance documents
[16:37.150 --> 16:46.410]  over the last, oh my gosh, you know, many years. And so, you know, whether it's pre-market
[16:46.410 --> 16:52.910]  requirements for submissions and cybersecurity, or it's post-market surveillance, right? And
[16:52.910 --> 16:57.270]  knowing how to do coordinated vulnerability disclosures, those guidance documents are very
[16:57.270 --> 17:04.190]  helpful. Also very relevant today, you know, is cybersecurity for off-the-shelf software
[17:04.190 --> 17:10.350]  components. Again, you know, FDA has some good guidance documents, a good guidance document on
[17:10.350 --> 17:17.230]  that. Recently, and, you know, they've taken a very collaborative approach to cybersecurity
[17:17.230 --> 17:23.030]  engaging very different stakeholders. And a great example of that, you know, FDA has engaged NTIA
[17:23.630 --> 17:30.790]  on creating a software bill of materials standard and a set of deliverables around that as well.
[17:30.790 --> 17:37.650]  And it's all around how manufacturers can be more ready to identify vulnerabilities in third-party
[17:37.650 --> 17:42.530]  components, and then extending that capability out to hospitals, you know, who have this technology
[17:42.530 --> 17:49.510]  in an operational environment. And, you know, the last two things here I'll mention is
[17:50.050 --> 17:55.810]  International Medical Device Regulators Forum. You know, it's not just the U.S. and FDA that's
[17:55.810 --> 18:01.490]  going through this problem. This is a global issue in medical device cybersecurity. And the
[18:02.050 --> 18:07.690]  International Medical Device Regulators Forum, INDRS, has come together to produce a cybersecurity
[18:07.690 --> 18:15.710]  guidance document that really sets to harmonize... provide harmonized guidance to regulators
[18:15.710 --> 18:21.490]  globally. So, you know, different countries and regions can set up their own guidance
[18:21.490 --> 18:28.730]  documents and map that to their own regulatory bodies. And the last one here I'll mention,
[18:28.730 --> 18:35.430]  I have to mention it because, boy, it was a lot of work, but the Healthcare Sector Coordinating
[18:35.430 --> 18:43.690]  Council. And, you know, Michael also and Mitch, you know, were contributors to this effort as well,
[18:43.690 --> 18:48.530]  produced what's called the Joint Security Plan, the MedTech Joint Security Plan,
[18:48.530 --> 18:54.310]  otherwise referred to as the JSP. And, you know, in this document, you know, anyone can find...
[18:55.170 --> 19:00.070]  it's not just... it's not standard. It's actually a plan, a way to put in motion
[19:01.250 --> 19:08.450]  a security program from design, development, all the way out to, you know, complaint handling for
[19:08.450 --> 19:13.530]  medical devices, and what to do when these devices are out in the field, and risk management,
[19:13.530 --> 19:17.550]  again, throughout the continuum of care. So if you want to know how to do a risk assessment
[19:17.550 --> 19:22.830]  on medical devices, if you want to know, you know, when to do a penetration test,
[19:22.830 --> 19:27.350]  what types of design requirements are helpful for medical device and cybersecurity,
[19:27.350 --> 19:33.110]  how to structure your organization, you know, those things you can find in the JSP today.
[19:33.110 --> 19:40.490]  And working with MDIC, we're also developing an effort to actually benchmark against those
[19:40.490 --> 19:46.990]  different capabilities. So that way, if you're a small medical device manufacturer or a large one,
[19:46.990 --> 19:52.470]  you want to know where to go next, and how to build out your program, and what's good enough.
[19:52.470 --> 20:01.570]  And so this benchmarking initiative with MDIC will help us create that set of metrics,
[20:01.570 --> 20:07.430]  and again, the benchmark itself, so that we can share it openly across our industry stakeholders,
[20:07.430 --> 20:12.870]  and collectively improve our programs, be able to speak to our executive leadership, too, as well,
[20:12.870 --> 20:18.010]  that have to pay and make and commit to this investment in medical device cybersecurity.
[20:18.010 --> 20:22.630]  That sounds really cool. Do they have guidance for manufacturers as well as providers?
[20:24.350 --> 20:32.230]  So, Healthcare Sector Coordinating Council also has, yes, guidance for healthcare providers,
[20:32.230 --> 20:39.130]  too. It's called HICP, H-I-C-P. And then you have the Joint Security Plan,
[20:39.130 --> 20:46.350]  which is focused on medical devices and healthcare IT solutions. And so, yes,
[20:46.350 --> 20:55.210]  they have guidance for both sets of stakeholders. Right. And yeah, so as Rob stated, the IMDRF,
[20:55.210 --> 21:04.050]  also, the way it was documented, it addresses, here's what's the pertinent areas for the
[21:04.050 --> 21:10.830]  manufacturer, the health delivery organization, the different stakeholders, even patients,
[21:10.830 --> 21:15.710]  as it pertains to the different topics that was put into that type of guidance. And again,
[21:15.710 --> 21:22.110]  that one was global. A couple of others that I would just want to make sure that we have included
[21:22.110 --> 21:30.030]  when you talk about health delivery organizations, MIDA has always championed and updated their,
[21:30.030 --> 21:37.230]  you know, MDS2 documentation, which is utilized for the procurement process with health delivery
[21:37.230 --> 21:44.270]  organizations. And that MDS2 is something that has been maintained as a part of the release schedule
[21:44.270 --> 21:50.390]  and with the inclusion of the SBOM as a component and a deliverable of that,
[21:50.390 --> 21:57.610]  it gives organizations like Mitch's the ability of being able to understand the ingredients of
[21:57.610 --> 22:02.990]  the product and the solutions that they are acquiring and how they need to develop and
[22:02.990 --> 22:10.810]  execute that. And then as Rob said, the AAMI organization has taken on the ability of taking
[22:10.990 --> 22:17.550]  a look at some of those, you know, pre-market and post-market type of guidance documentation,
[22:17.550 --> 22:24.830]  and then they created their technical, you know, references in their TIR 57 and 97, which allows
[22:24.830 --> 22:31.470]  you to provide some of the how-to on those different stakeholders in the industry, how they
[22:31.470 --> 22:38.190]  need to execute against those particular technical references and standards. So I think that kind of,
[22:38.190 --> 22:45.850]  we gave you the alphabet soup and then some in response, Mitch. Yeah, absolutely. No excuses now.
[22:46.970 --> 22:51.970]  I can tell you that that 2019 MDS2 form, thank you very much for that, Michael. That's been
[22:51.970 --> 22:57.030]  incredible in our organization. We've actually started using that a lot. The first vendor that
[22:57.030 --> 23:04.050]  actually gave us one was Philips. So very happy that... I'll take the old pats on the back for
[23:04.050 --> 23:07.030]  that. We're starting to get those in from our vendors and they've been helping us out with a
[23:07.030 --> 23:14.550]  lot of different purposes. So my next question here is, what are the most difficult medical device
[23:14.550 --> 23:19.190]  security issues to solve? I want to throw a real ringer in there.
[23:22.670 --> 23:29.650]  I'll take the first. Okay, go ahead, Rob. Yeah, I'll take a first stab at that. So
[23:30.710 --> 23:36.450]  I think one of the most difficult issues to solve, just to change it up here, aside from...
[23:37.010 --> 23:43.930]  and it does relate to the issue of legacy medical devices, is also that hospital environments
[23:44.290 --> 23:51.710]  may have hundreds of thousands of connected medical devices at one time and from thousands
[23:51.710 --> 24:03.110]  of different vendors. And so while I may not directly feel that pain, I feel for our customers
[24:03.110 --> 24:10.930]  at BD that are healthcare providers and have to manage this tremendous complexity.
[24:11.710 --> 24:19.610]  And what compounds this situation is that not every medical device manufacturer
[24:19.610 --> 24:27.310]  is doing things like patching of their medical devices or routine updates to their medical
[24:27.310 --> 24:37.290]  devices. And also, that's why transparency is so important, because these new threats emerge
[24:37.290 --> 24:44.330]  daily. And boy, I'm sure there's a lot of homework that healthcare providers have to do when a new
[24:44.330 --> 24:51.710]  security vulnerability pops up and you don't find a timely and effective or meaningful communication
[24:52.230 --> 25:01.130]  from a medical device manufacturer to facilitate a response. So yeah, I think those are
[25:01.950 --> 25:06.690]  really, really important issues that we need to address.
[25:07.450 --> 25:15.150]  You know, one of the things I would add on where Rob is at, and again, I do agree that the
[25:15.770 --> 25:21.410]  level of connectivity and the complexity of the type of solutions is definitely
[25:22.530 --> 25:28.030]  a critical one, but let me be a little bit more provocative and throw something else out there.
[25:28.030 --> 25:35.990]  I think when you look at potentially, and again, and this gets back to, again, I think
[25:35.990 --> 25:42.350]  where Florence was at when we talk about taking it down to the chip level. I think when I look
[25:42.350 --> 25:50.990]  at the greed that exists in society around the revenue that either wants to be made or
[25:50.990 --> 25:58.170]  maintained on devices, and then what that would be from your brand and impression. I think one of
[25:58.170 --> 26:06.650]  the best things that happened was the fact when the Health Sector Coordinating Council and HISAC
[26:06.650 --> 26:12.510]  and others have come together and petitioned organizations like Microsoft, especially during
[26:12.510 --> 26:20.810]  this time of COVID, to extend the patching and the updates for Windows 7 and to make that
[26:20.810 --> 26:28.410]  date in the hospital sector not to extend it. So the more that we can
[26:28.410 --> 26:36.790]  do activities as a community like that to either extend the life or to be much more
[26:37.670 --> 26:44.010]  economical around how these products and solutions are being used. And again,
[26:44.010 --> 26:50.670]  my provocativeness, get away from the potential greed that might exist out there. I think
[26:50.670 --> 26:57.230]  that'll help us to try to address some of the issues that might exist
[26:57.230 --> 27:00.750]  in the ecosystem. It's one thought.
[27:04.470 --> 27:11.990]  Yeah, greed and jealousy are motivators that we can use in business to get people to do
[27:11.990 --> 27:20.130]  things. And so it's the human condition, I think. So if we could
[27:20.130 --> 27:27.110]  figure out how to leverage that, I think that would be good. So in the standards work that we do,
[27:27.570 --> 27:32.930]  you know, it's IEEE, it's at the individual level, it doesn't cost anything to join the
[27:32.930 --> 27:37.010]  working group. And what I tell people is, you know, this will be like a take-home test
[27:37.010 --> 27:42.010]  if you get involved now, because you can help define it, you know, and then you could be the
[27:42.010 --> 27:46.730]  first ones to have it. And you could be at the leading edge when, you know, I was at Yale New
[27:46.730 --> 27:52.050]  Haven a couple years ago talking about this tips framework, and very bright as they are,
[27:52.050 --> 27:55.790]  the chief information and chief medical officers looked at me and said,
[27:55.790 --> 27:59.750]  so do you have a tips maturity model that you could hand us today that we could use tomorrow
[27:59.750 --> 28:03.490]  to look at all these hundreds of thousands of devices in our hospital and our patients?
[28:03.490 --> 28:09.030]  Like, whoa, I wish the answer to that was yes, but it's going to take a village, right? Ah,
[28:09.030 --> 28:13.070]  the biohacking village, look where we are, how handy is this? So maybe that's something, you
[28:13.070 --> 28:17.930]  know, we can end up working on together. And people can get involved in creating this tips maturity
[28:17.930 --> 28:23.650]  model, validating it, certifying it, you know, maybe that's, you know, what we can do is get
[28:23.650 --> 28:28.390]  other people jealous, like, ooh, you know, I want to go to the head of the class. That would be great.
[28:30.130 --> 28:35.170]  I, I agree with you. And I think, and again, there's other challenges as well. And I'm going
[28:35.170 --> 28:39.170]  to be just as provocative as Michael right here and bring out another big one, which is the
[28:39.170 --> 28:46.270]  electronic medical records systems of record themselves. So we have to make sure that these
[28:46.270 --> 28:51.370]  systems of record that we eventually store all this information in, we have to make sure we keep
[28:51.370 --> 28:59.450]  them as updated and up to date and able to support these devices just as much as the devices
[28:59.450 --> 29:03.590]  themselves. There was actually an interesting paper I read from the late Michael Sinow and
[29:03.590 --> 29:10.190]  some other people that had put together the best model for electronic medical record system
[29:10.190 --> 29:17.170]  implementation at a health system in New Jersey they were at. And what it came down to is that
[29:17.170 --> 29:26.350]  25% of the cost was the EMR. 75% was the cost of the ancillary devices themselves. So I think
[29:26.350 --> 29:32.870]  we could stand to make sure that we have a good budgeting model that we make sure that we
[29:32.870 --> 29:41.130]  understand what devices work, what version of an EMR and be able to cost it all out. And we can solve
[29:41.130 --> 29:48.210]  that challenge with simply doing a lot of good financial work and making sure also that the
[29:48.210 --> 29:55.970]  system of record aka the EMR also stays updated. Easier said than done. So talking about other
[29:55.970 --> 30:00.190]  challenges to your future leads to question number four which is how do you solve the
[30:00.190 --> 30:07.930]  challenges today with an anticipatory eye and what the next threats may be?
[30:07.930 --> 30:13.330]  First on that right here I'll start off again with Florence. Oh heads down display heads up
[30:13.330 --> 30:18.850]  display. What is it you're trying to deal with today? And we have we'll start with with that
[30:18.850 --> 30:23.950]  and we have to have the guts to look at what we haven't done yet. Now we're all talking about
[30:23.950 --> 30:27.490]  standard this you know we haven't done with SNOMED and low ink and this and that and fire
[30:27.490 --> 30:31.330]  and HL7. Oh my god this stuff is so incredible because people who are brilliant who created it
[30:31.330 --> 30:36.670]  right. But it's not done and it will probably never be done right because there's a lot of
[30:36.670 --> 30:42.890]  hacking that you know continues to evolve as we know. The the bad dudes and dudettes and robots
[30:42.890 --> 30:48.610]  are just as smart as the good ones unfortunately. So what we have to do is not be afraid to look
[30:48.610 --> 30:53.970]  at what haven't we done yet. So as an example so we're talking about trust and identity and
[30:53.970 --> 30:59.670]  security and devices. So what if we had you know what if we figured out a federated identity
[30:59.670 --> 31:04.690]  management system for devices with you know digital identifiers, decentralized identifiers,
[31:04.690 --> 31:09.630]  and we try to do that globally. People go oh we haven't done that yet. I'm like exactly
[31:10.150 --> 31:17.330]  that's exactly the point. So is that exactly what we need? Maybe not. But go wide and then decide
[31:17.330 --> 31:22.430]  you know how we start today and where we need to go. So we have the guts we have to have the guts
[31:22.430 --> 31:28.790]  to say we haven't figured it all out yet. Figure out what we can do today and then build a step
[31:28.790 --> 31:33.690]  function you know a plan going forward. And you know you should we should do some brainstorming
[31:33.690 --> 31:38.410]  like I was about holograms and VR and AR and XR and your R and my R and all this other kind of
[31:38.410 --> 31:42.550]  stuff that's going to happen. And stuff that we don't even have terms for yet. They're going to
[31:42.550 --> 31:48.730]  be part of this. So I'd say that you know we have to start by being brave enough to understand what
[31:48.730 --> 31:52.650]  we already have from AIME and ISO and IEC and IEEE and all this other cool stuff and all the
[31:52.650 --> 31:58.250]  providers and all the manufacturers. Then look at what we haven't done yet. Have the guts to do that.
[31:58.250 --> 32:02.450]  Figure it out and then create a step function toward the future. So that's my recommendation.
[32:03.020 --> 32:10.730]  Yeah I love the comments from Florence and the direction. I've built a few homes
[32:10.730 --> 32:17.530]  because of having to relocate. And I always look at what your current environment is
[32:17.530 --> 32:23.730]  as an organization, as a team. And to her point, I want to make sure that foundation is in place.
[32:23.730 --> 32:30.510]  And one of the biggest hurdles is to be able to consistently execute in a number of these
[32:30.510 --> 32:37.410]  organizations that foundational piece that she described. In terms of making sure that
[32:37.410 --> 32:43.090]  we're doing consistently the activities and efforts that we should have in place right now.
[32:43.090 --> 32:49.910]  And so when you have multinational organizations, different business units,
[32:49.910 --> 32:57.390]  different variations of releases and schedules of products and devices, different mixes of
[32:57.950 --> 33:03.990]  solutions, whether or not they're capital related or implantables. And I mean,
[33:03.990 --> 33:09.670]  there's a myriad of things that exist out there, but you have to be pretty consistent with
[33:09.670 --> 33:15.070]  how am I developing that solution? How am I maintaining that? How am I updating that? How
[33:15.070 --> 33:20.350]  are we interacting and getting the right information at a consistent level like those
[33:20.910 --> 33:28.170]  MDS2s updated on that entire product portfolio? That's the basics in terms of the blocking and
[33:28.170 --> 33:35.210]  tackling that usually isn't the most sexy thing that you think of, and sometimes is really
[33:35.210 --> 33:42.310]  overlooked. And so we really need to get that foundational areas in place across all of the
[33:42.310 --> 33:50.110]  elements of, as we say in the ecosystem, for devices and solutions. And even as Mitch just
[33:50.110 --> 33:56.250]  pointed out from his earlier statements around the electronic health and medical records,
[33:56.830 --> 34:01.910]  Rob and I know that our counterparts in some of those entities, when we were on the cybersecurity
[34:01.910 --> 34:06.610]  task force, it was like pulling teeth to get them to want to even come to the table
[34:07.150 --> 34:11.990]  and having the discussions. And even when you have certain solutions where
[34:12.610 --> 34:19.530]  we're there was astonished to say, man, you had the ability to maintain the certain level
[34:19.530 --> 34:28.210]  of the release and not go back multiple inversions. But you did that to want to be
[34:28.210 --> 34:33.830]  supposedly in compliance and supporting your customers, but you were doing a total detriment
[34:33.830 --> 34:39.670]  to the industry by not aligning and forcing that you couldn't have stuff out there. But
[34:39.670 --> 34:45.950]  they were in a much easier position to maintain their devices at the most current levels and
[34:45.950 --> 34:50.630]  updates. And we were sitting there like, man, are you kidding? Because we don't have that luxury
[34:50.630 --> 34:57.890]  when it came to some of the devices, especially for organizations that had implantables and pumps
[34:57.890 --> 35:04.090]  and other things of those natures. So... Don't hold back, Michael.
[35:04.930 --> 35:14.910]  It's DEF CON. So when I think about what we can do right now, I think about the current
[35:14.910 --> 35:21.070]  environment that we're in. And it touches on a little bit of what you've heard
[35:21.070 --> 35:27.130]  from others on this panel, actually. We're in an environment where I think most of our
[35:27.130 --> 35:34.010]  organizations, if you work in healthcare, we're distracted. Really distracted. If you're even just
[35:34.010 --> 35:41.430]  the general public, you're distracted. Okay? COVID has taken a lot of the focus away from
[35:41.430 --> 35:50.030]  other things like cybersecurity. If we're not careful in tying the story behind how cybersecurity
[35:50.550 --> 35:56.910]  is the underpinning to providing a resilient and thriving healthcare system.
[35:57.030 --> 36:05.690]  It's just essential. We can't have resilient and effective healthcare without securing it.
[36:05.690 --> 36:12.750]  They go hand in hand. And I say that because the other issue we're facing here is that
[36:13.070 --> 36:20.670]  most healthcare delivery organizations don't even have a single person dedicated to
[36:20.670 --> 36:26.890]  cybersecurity. And this is one of the findings of the Healthcare Industry Cybersecurity Task
[36:26.890 --> 36:35.570]  Force report that went to Congress in 2017. So there's not enough people working in this space
[36:35.690 --> 36:42.450]  we need to bring in more stakeholders from different backgrounds into the healthcare
[36:42.450 --> 36:49.910]  industry and into the cybersecurity industry to really... and even if it's not their title,
[36:49.910 --> 36:56.730]  but to build a community of practice around everyone's shared responsibilities around
[36:56.730 --> 37:03.350]  cybersecurity. And the last thing I'll say from the stuff that we can control as the cybersecurity
[37:03.350 --> 37:14.130]  professionals, I think especially Michael and Mitch and myself, we need to as healthcare and
[37:14.130 --> 37:19.590]  medical technology companies, as healthcare providers, we need to look at our investment
[37:19.590 --> 37:27.490]  in security and ask ourselves this, are we protecting what society values most?
[37:27.490 --> 37:34.450]  And if you ask anyone, what is important to protect in healthcare to protect,
[37:34.450 --> 37:41.050]  they will tell you most likely, even if it's my mom, all right, she will tell you,
[37:41.050 --> 37:47.590]  it's probably going to be patient safety, patient health, right? And probably also patient privacy.
[37:48.510 --> 37:55.570]  And so look at our investment today and figure out if there's changes that we need to take in
[37:55.570 --> 38:02.470]  our approach. And maybe touching on Florence's idea there to make it even more tangible around
[38:02.470 --> 38:08.150]  creating some sort of model for identity management in healthcare, you don't have to go
[38:08.150 --> 38:15.070]  too far. I mean, for many years, the cybersecurity industry has been talking about what's called
[38:15.650 --> 38:23.230]  zero trust principles. And so the idea behind zero trust principles are instead of trusting
[38:23.230 --> 38:29.390]  devices inside the network, you know, in this approach, it means trusting no one by default
[38:29.390 --> 38:35.690]  and operating as though the network had already been compromised. And so this means incorporating
[38:35.690 --> 38:41.470]  different types of criteria for authenticating and authorizing users. And the fundamental
[38:41.870 --> 38:47.570]  technologies exist today. It's just changing your strategy as a cybersecurity professional
[38:47.570 --> 38:52.410]  to focus on the idea that you've already been compromised. And how do we strengthen authentication
[38:52.410 --> 38:58.530]  through multi-factor authentication, through conditional access for devices and users
[38:58.530 --> 39:04.610]  connecting to the network? And so those types of technologies exist today. There is hope in,
[39:04.610 --> 39:09.710]  again, what's available to cybersecurity professionals today. But I would also go
[39:09.710 --> 39:14.890]  back and say, we need to expand our community of practice. So if we get all geeky-weeky,
[39:14.890 --> 39:18.310]  which we could do with each other, fire this and HL7 that, and we're so cool,
[39:18.690 --> 39:25.730]  you know, trust zone and hardware. I got upgraded for free one day on a plane when I was flying
[39:25.730 --> 39:30.250]  planes. And I was sitting next to a guy who runs a hospital, a doctor. And I was telling him what
[39:30.250 --> 39:33.750]  we're doing. He said, well, you know what? I'm glad you're working on that because my job is
[39:33.750 --> 39:40.990]  to keep that patient on the table alive. That's what I focus on all day. So in our working group,
[39:42.330 --> 39:49.410]  2933 working group, actually it's all about, we always talk about it, protecting the humans,
[39:49.410 --> 39:54.890]  keeping the humans alive. That's why we're doing this. That's exactly why, you know, my background,
[39:54.890 --> 39:58.610]  my mother died the day I was born. It was a medical error, you know, whole stuff here. So
[39:58.610 --> 40:03.530]  I carry this with me. How do you keep the humans alive? And that's what we're focused on. And if
[40:03.530 --> 40:08.170]  you actually read our project authorization request at IEEE, it says to improve health
[40:08.170 --> 40:12.670]  outcomes. We're not doing this for us geeky weekies. We're doing it to improve health outcomes
[40:12.670 --> 40:18.690]  and to keep the humans alive. And eventually what I would love to see, and we actually had a meeting
[40:18.690 --> 40:24.210]  at my last firm and with Microsoft a few years ago, we were talking about creating like a
[40:24.210 --> 40:28.930]  cybersecurity learning hub for humans, you know, normal people. And we said, oh, cradle to grave.
[40:28.930 --> 40:33.870]  And we said, oh, that's kind of rude. Let's say pre-K to AARP. And we're going to teach them
[40:33.870 --> 40:38.730]  what TIPS is. You know, so when I was a little girl, remember I'm a geek, I was a rocket scientist. So
[40:38.730 --> 40:44.470]  I used to look for the little UL tag on my, on my electric cords. Any of you guys? I did. I always
[40:44.470 --> 40:50.970]  look for them because that meant safety, right? And so what we want to do is teach them why they
[40:50.970 --> 40:55.370]  should ask for this. So someday, I don't know if it's two, three or five years from now, some little
[40:55.370 --> 40:58.870]  five-year-old is going to be at the doctor and they're going to try to give her an insulin pump.
[40:58.870 --> 41:04.530]  And she's going to say, does that have TIPS? And she doesn't need to know what it stands for.
[41:04.530 --> 41:10.170]  We do. We're the geeks. We need to understand that it's trust and identity and federated identity
[41:10.170 --> 41:14.770]  management. And when the doctor, you know, goes into the little device next to grandma's bed that
[41:14.770 --> 41:20.890]  goes into her implanted pacemaker, you check the credentials of that doctor every single time.
[41:21.110 --> 41:26.170]  You make sure they're still, you know, related to whatever their provider is. You make sure they
[41:26.170 --> 41:31.170]  still are credentialed. You make sure it's really the doctor and you have to figure out how to do it.
[41:31.230 --> 41:36.570]  So that's our vision is that we really want this to protect the humans and make the humans aware of
[41:36.570 --> 41:41.270]  it. Just like I looked for that little UL tag, which not everybody did, I know, but you know,
[41:41.270 --> 41:45.770]  how do we teach them and then make sure that the manufacturers are delivering that because
[41:45.770 --> 41:50.790]  then you have demand, you have push and pull from the citizens, from the patients, right?
[41:50.790 --> 41:55.350]  And then the providers and the payers should care about this. It reduces their liability.
[41:55.350 --> 41:59.390]  You know, I used to work on smart buildings years ago when we were first creating a smart
[41:59.390 --> 42:05.070]  building strategy when I was a VP at IBM. And I remember, you know, we were talking to these
[42:05.070 --> 42:09.230]  building management system companies and one of them said, oh, you know what? Security is like
[42:09.230 --> 42:13.610]  number 11 on my list of top 10 things to worry about. And their device was hacked nine months
[42:13.610 --> 42:19.190]  later and the whole leadership team was out. And now it's part of their brand promise. Oh,
[42:19.190 --> 42:24.830]  imagine that, right? So we need to make that a requirement. You know, we need people to be
[42:24.830 --> 42:30.430]  incented to do that and to have the citizens and patients asking for it.
[42:31.650 --> 42:37.650]  Absolutely, Florence. And also one other thing that my organization's had a big challenge with
[42:37.650 --> 42:44.430]  has also been privacy because one of the areas we've got to worry about is not only do we have,
[42:44.430 --> 42:50.090]  we're collecting all this data on people and we have numerous data points on all the people we're
[42:50.090 --> 42:54.990]  collecting from these devices. And we need to make sure that we're protecting that. So
[42:54.990 --> 43:01.290]  important question I have here is what about privacy? How are we incorporating this into
[43:01.290 --> 43:06.510]  our products? How are we incorporating it into our data governance plans? So to lead off here,
[43:06.510 --> 43:14.170]  I believe this is going to be our final question for the three of you. So start off with Michael.
[43:14.710 --> 43:22.170]  Sure. I think that the, you know, privacy takes on, you know, from a legal perspective,
[43:22.170 --> 43:29.070]  you want to understand, you know, the requirements by the different geographies,
[43:29.070 --> 43:34.770]  by the different jurisdictions, by, you know, what the hospitals and, you know,
[43:34.770 --> 43:40.590]  the different entities have in terms of managing that type of information. But to me, Mitch, it's
[43:41.350 --> 43:47.510]  nothing more than another component of your requirements. So if you design privacy as you
[43:47.510 --> 43:52.790]  would security by design in your development process, you take into account what are those
[43:52.790 --> 43:58.430]  sets of requirements and you have to harmonize for, you know, some of us, you know, like, you
[43:58.430 --> 44:06.070]  know, Rob and I and others out there that deal in multi, you know, geographies, you know, multi
[44:06.070 --> 44:13.130]  types of regulatory and compliance environments, and you have to develop what your baseline is.
[44:13.130 --> 44:17.630]  And then once you develop that baseline, and you include those sets of requirements,
[44:17.630 --> 44:23.510]  I would look at the steward of, you know, the CISOs, you know, and it's three of us on the call
[44:23.510 --> 44:29.550]  to be able to make sure that we're executing against that. We go to our legal teams and the
[44:29.550 --> 44:35.410]  privacy organization, really for that foundation to make sure that we're interpreting those
[44:35.410 --> 44:40.570]  requirements, and we're executing those requirements, you know, effectively with the
[44:40.570 --> 44:47.970]  tools and the solutions that we then deploy out in the marketplace. And so I have always had,
[44:47.970 --> 44:55.070]  you know, kind of a mix of the privacy and the data protection elements kind of be able to be
[44:55.070 --> 45:00.990]  co-mingled within, you know, the team. Operationally, if you do it right, you want the CISO side of the
[45:00.990 --> 45:06.150]  house to be managing that, and you want your legal and your compliance arms to be able to
[45:06.150 --> 45:12.290]  help you develop and, you know, and document what those requirements need to be, you know,
[45:12.290 --> 45:20.440]  from a privacy perspective, in my opinion. So I got to tell you, I don't think I could
[45:20.440 --> 45:30.400]  describe it any better than Michael, or I should say Professor McNeil. It's so well said, really,
[45:30.400 --> 45:37.780]  I can't do better than that. I mean, you know, to address privacy requirements alongside security
[45:37.780 --> 45:43.540]  requirements, I absolutely agree. As security professionals, like, you know, bring your privacy
[45:43.540 --> 45:50.140]  friends along with you. And absolutely right that, you know, there's things that, you know,
[45:50.140 --> 46:00.380]  we think of in security that sometimes are counterintuitive to privacy. And then also,
[46:00.380 --> 46:06.480]  again, what Michael said around, you know, treating, bringing your legal professionals,
[46:06.480 --> 46:11.320]  especially, you know, when you're addressing privacy requirements, the complexity is,
[46:11.320 --> 46:18.060]  as he mentioned, this is different across every single country. And you do have to,
[46:18.060 --> 46:25.980]  you know, establish as a company, a common foundation, based off of values, based off
[46:25.980 --> 46:31.440]  of values and principles, you know, as a company, what do we stand for? What is it that we want to
[46:32.060 --> 46:41.720]  do when it comes to this huge civil rights issue, you know, of privacy? And sometimes that means we
[46:41.720 --> 46:46.280]  want to do everything that we can, and we are going to establish, you know, the strictest,
[46:46.280 --> 46:51.480]  you know, governance of privacy across all of our technologies and product platforms, you know,
[46:51.480 --> 46:56.240]  that is, again, a decision that companies need to make. And I got to tell you, I don't think
[46:56.240 --> 47:03.420]  there's many customers that would complain, you know, about a company creating a position
[47:03.420 --> 47:08.460]  and a very robust and comprehensive position on privacy across their different technologies for
[47:08.460 --> 47:14.100]  customers. So... Agreed. So I'll make a couple of comments. I'm sorry, Mitch. I couldn't agree
[47:14.100 --> 47:19.680]  more with you. So what do you think? Oh, you know, Mia, I always think something. So there
[47:19.680 --> 47:24.360]  are a couple of things. One is on the privacy side, it's one of our subgroups, it's part of
[47:24.360 --> 47:28.320]  TIPS, you know, Trust, Identity, Privacy, right in the middle, Protection, Safety, and Security.
[47:28.320 --> 47:32.520]  And we have a woman from the European Union who's leading that subgroup, which is great,
[47:32.520 --> 47:39.400]  because she actually found the privacy rules by country in Europe. Not surprising, right?
[47:39.400 --> 47:44.540]  So what we're doing is making sure that we're going deep on those, identifying the patterns,
[47:44.540 --> 47:48.580]  and then figuring out what are the little things we have to worry about here if we're creating a
[47:48.580 --> 47:53.420]  standard that's international. So if I'm wearing an implanted device, I'm in the U.S., I'm in the
[47:53.420 --> 47:57.560]  U.K., I'm in Russia, I'm in China, I'm in South Africa, am I going to be safe? You know, is my
[47:57.560 --> 48:01.840]  data going to be private? What does that mean? What are the implications? So we're already baking
[48:01.840 --> 48:09.840]  that in to the plan. The other thing is that I was at an event at my alma mater at Princeton,
[48:09.840 --> 48:13.880]  and Sonia Sotomayor was there. She's a Supreme Court Justice in the U.S. for those of you who
[48:13.880 --> 48:18.580]  don't know her. She's brilliant. And so I asked her, what do you think about privacy and security
[48:18.580 --> 48:22.740]  and the Internet of Things, all these devices all over the place? I said, I'm working on security.
[48:22.740 --> 48:27.700]  She said, that's good because I'm working on privacy because I don't think the citizens realize
[48:27.700 --> 48:32.740]  the human rights that they're giving up. Very interesting. So she's on it, and she's already
[48:32.740 --> 48:36.960]  written a couple of things on it if you want to look at what she's done. And then the other thing
[48:36.960 --> 48:41.300]  I just want to mention very quickly, we were talking about, you know, what's our goal here?
[48:41.300 --> 48:45.480]  I spoke at an event at Academic Medical Center Conference a few years ago, and then about a year
[48:45.480 --> 48:50.320]  or so ago, a gentleman reached out to me and said, oh, I wrote a book, and I found your presentation,
[48:50.320 --> 48:54.920]  and I referred to you in my book. I was like, oh, I'm so honored. What's the name of your book?
[48:54.920 --> 49:03.380]  The Doctor Will Kill You Now. And he talked about the security and privacy issues,
[49:03.380 --> 49:08.660]  and this guy who, like, you know, lives in his mother's basement and then moves to another
[49:08.660 --> 49:13.180]  state. It's not bad living in your mother's basement, I have that going on too, but moves to
[49:13.180 --> 49:20.520]  another state, fakes a PA license, gets into a doctor's office, gets into the system, actually
[49:20.520 --> 49:27.380]  turns off the power in the hospital so someone on event dies. Then he gets into somebody's personal
[49:27.380 --> 49:32.880]  medical record, changes his blood type, they're given a transfusion, and they die. And then his
[49:32.880 --> 49:39.700]  next target is a children's hospital. So if anybody is looking at, so why should I worry
[49:39.700 --> 49:45.640]  about this security and privacy stuff? That's a good book. It's only 15 bucks. And the guy who
[49:45.640 --> 49:51.400]  wrote it is an MD, and he used to lead the IEEE chapter in Rochester, New York, years ago.
[49:51.400 --> 49:56.900]  So he, you know, he's on both sides. He's an electrical engineer, computer scientist, more double
[49:57.440 --> 50:03.720]  and then he's also a doctor. So we all have to work on this. This is serious. It's just going
[50:03.720 --> 50:09.360]  to get worse. A lot more things are connected. There are attack surfaces all over the place.
[50:09.360 --> 50:16.920]  We need a defense in depth strategy. And it's for privacy and security and protection and safety.
[50:21.830 --> 50:26.790]  I'm impressed by the depth of knowledge everyone brings here. And I speak from the provider
[50:26.790 --> 50:31.890]  perspective here. I'm very happy to be working with you all, especially from the standards
[50:31.890 --> 50:37.410]  perspective as well. I think we have a good foundation. We just all need to continue to keep
[50:37.410 --> 50:43.790]  working together. And you have my commitment and for all of you in the medical device industry know
[50:43.790 --> 50:49.290]  you have my organization's commitment as well. So thank you so much for all taking the time today.
[50:49.290 --> 50:55.350]  This is incredibly appreciated and hope all of you out there appreciate this today as well. So
[50:55.350 --> 51:00.430]  thank you all so much for taking the time. And this is the group here signing off.
